This topic discusses how to achieve data center resiliency through a decentralized approach that distributes assets across multiple geographic locations.
In the past, building data center resiliency involved creating a high degree of redundancy within a single facility. This model worked well with highly consolidated architectures where most applications and services were concentrated within that data center. But this is no longer the case. Applications, resources, and users are distributed more than ever.
In contrast to a centralized approach, geo-redundancy typically involves distributing assets across locations, instead of highly available single deployments. This allows for resources to be more local to users for better experience, whilst ensuring continuity in the event of an outage by failing over to adjacent metros. By having multiple resource on-ramps across metros, it's more acceptable for single points of failure to be present in any given metro, as resources are available elsewhere.
One of the challenges with distributing assets geographically in a traditional data center model is the ability to access and manage that infrastructure. Typically, that would require hands and feet on the ground in every location.
Network Edge provides capability that fits the geo-redundant model well. It offers highly connected infrastructure, close to clouds and networks, as well as the ability to deploy, configure and manage global networking infrastructure from anywhere.
Architecture
The geo-redundant design in this reference architecture is deployed across just two metros. However, this approach can scale to any Network Edge-enabled location, providing a higher degree of fault tolerance. As described above, each metro deployment provides more localized access to the resources being consumed, but more importantly, provides a path to consume those resources through an alternate metro in the event of a failure.
The deployment shown below is comprised of a three-tier architecture, consisting of a router, a firewall, and an SDWAN appliance in both metros. However, this approach can be applied to any of the use cases outlined in this document. The idea is to create a templated approach based on the specific connectivity requirements. This consistent design can then be deployed across the Network Edge infrastructure, closer to users and resources. It's to this point that care should be taken with the deployment locations to ensure that cloud, ISP (Internet Service Provider), and NSP (Network Service Provider) services are available in that metro. This is further outlined in the Considerations section below.
Equinix Components
-
Equinix Fabric – Equinix Fabric is a switching platform that provides private connectivity to a wide selection of providers that are participants on the Fabric. Virtual circuits are provisioned on the Fabric using software-defined networking to establish connectivity to providers that are connected to the Fabric. Virtual connections can be created using the Fabric Portal or APIs.
-
Equinix Network Edge – Network Edge is an ETSI-compliant NFV platform that hosts VNFs (routers, firewalls, and SD-WAN) from various vendors such as Cisco, Juniper, Palo Alto, Fortinet, Versa, Aruba, and Check Point. VNFs can be deployed in real-time and, once deployed, you can start building virtual connections to providers on the Fabric.
-
Equinix Device Link – A globally available VPLS service that is unique to the Equinix Network Edge offer. It allows for multiple devices to be put into a single, fully meshed, broadcast domain.
Cloud Service Provider (CSP) Components
-
Private interconnection – Private interconnections from the CSP are Layer 2 partner or hosted connections that connect to the Equinix Fabric. Partner or hosted connections provide an intermediate switch between a device and the CSP router it peers with. Once the private Layer 2 interconnection has been established, you can set up Layer 3 peering with the CSP gateway. Private interconnections bypass the internet.
-
Cloud gateway – The cloud gateway is a software-defined router that is instantiated in the CSP network and connected to the virtual private cloud. The cloud gateway is used to establish BGP peering to the Network Edge device and is attached to the virtual private cloud (VPC) providing reachability between clouds.
-
Virtual private cloud – The VPC is a virtual network that serves as the container to deploy subnets and other networking constructs to instantiate compute and other application services.
Network Service Provider
-
Private interconnection – Depending on the level of integration that a NSP has with Equinix Fabric, connectivity can either be through a software-defined interconnect (for select, pre-integrated providers) or the BYOC workflow (for service providers who are not integrated into Fabric). Customers are still required to maintain a contract/arrangement with the NSP for connectivity beyond the private interconnection facilitated by Equinix Fabric.
Recommendations
These recommendations provide a starting point. Customer requirements might differ from this list.
Choice of Location
One of the principles of interconnection is that it be close to the resources that are being consumed. In relation to this architecture, this means the proximity of Equinix’s Network Edge infrastructure to the NSP and CSP edges. Not every CSP has an on-ramp in every location. The same applies for the edges of a NSP’s network and Equinix’s Network Edge infrastructure.
To keep the network latency as low as possible, it's recommended that you select a metro that has the best interconnection to the providers that you need. One helpful resource is the Equinix Service Provider Availability Page, which shows which providers are local to which metros.
Network Edge locations can be found on the Network Edge Data Sheet.
High Availability
This high-level design shows a single end-to-end connection from NSP, to virtual appliance, to cloud.
Some CSPs mandate redundant private connectivity, such as Microsoft Azure ExpressRoute. This presents as two virtual circuits within the Equinix Fabric and while both circuits can be connected to a single virtual appliance, there are considerations around creating VNF level diversity.
Network Edge offers the ability for highly available and clustered (for select VNFs) appliance deployment models.
Careful consideration should be given to the design of solutions to ensure that service impacting events are minimized.
Network CIDR Blocks
To avoid requirements around NAT/PAT, select CIDR blocks that don't overlap with any other network (in your network, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
Considerations
When implementing this architecture, consider the following factors.
Performance
Performance of the solution depends on several factors, namely the latency between each environment, the bandwidth of the virtual circuits deployed, as well as the throughput of the virtual appliance. All of these should be considered during the design phase of the deployment to ensure optimal performance of the solution.
Security
Private interconnections on the Fabric to the cloud provider are not encrypted. Additional measures should be taking to ensure in-flight traffic is encrypted. The method for doing so depends on the security requirements, but can be done at either the network layer or at the application layer.
Equinix Costs
-
Device instance – The cost for the virtual device (does not include the license cost).
-
License for the virtual device – Customers can purchase a subscription license for some vendors. Bring Your Own License (BYOL) is available for all vendors.
-
Virtual circuits – Monthly recurring charges are based on the size of the circuits. Connections between metros across the Equinix Fabric incur an additional surcharge for the remote connection.
-
Equinix Fabric Port – The cost for the port if BYOC is used to connect NSP/ISP.
CSP Costs
-
Egress Charges – Charged by some service providers based on the amount of data that is transmitted over the private interconnection. These charges vary based on the provider. Using a private interconnection reduces the egress charges when compared to the Internet.
-
Private Connectivity Charges – Most CSPs will charge a monthly recurring cost for the private circuit into their environment. Both egress and connectivity charges factor into your application design.
NSP Costs
Any charge incurred by the NSP is billed directly from the NSP.
Scalability
While this reference architecture focuses on a limited number of Network Service Providers, Cloud Service Providers and metros, this architecture can scale to any location that Equinix has deployed Network Edge infrastructure.
Related Topics